前言

回到昨天的題目，我們只模擬尖峰時段，大量的購物車加入商品的測試場景，但實際運行環境上，可能會不同的使用者做著不同的事情：購買商品、搜尋商品、加入到購物車、移除商品到購物車、結帳和付款等等。就像《火影忍者》裡的「影分身之術」吧！當主角鳴人同時分出數十個影分身，每個分身都在做不同的事：戰鬥、學習、探查，這就像我們的系統在面對多任務負載時的挑戰！

挑戰目標

模擬一個視訊串流平台的高負載場景，並測試系統在同時進行多任務操作（如影片上傳、即時觀看、評論、搜尋）的情況下，是否能保持系統穩定。

挑戰設計測試場景：

• 場景 1：模擬用戶大量上傳影片，並且同時進行即時觀看，測試系統的寫入和讀取性能。
• 場景 2：在用戶大量提交評論的時候，同時進行影片的搜尋，測試系統在高頻率讀寫操作中，是否能夠維持回應的速度。
• 場景 3：模擬影片上傳的瞬間尖峰，同時用戶進行多條影片的即時觀看和評論，測試系統是否能夠承受高並發操作並平穩恢復。

測試背景資訊

系統架構

graph LR
    A[Load Balancer] --> B[Web Servers]
    B --> C[Media Servers]
    C --> D[Content Delivery Network]
    B --> E[Cache Layer]
    C --> F[Database Cluster]

• 負載平衡 (Load Balancer)：用來幫忙分流的伺服器，用來將用戶分流到不同的 Web 伺服器。
• Web 伺服器 (Web Server)：用來處理使用者請求並且轉址到影片播放服務。
• 媒體伺服器 (Media Servers)：負責影片的編碼與傳輸。
• 內容傳遞網路 (Content Delivery Network)：加速影片內容的傳輸，通常會分布在不同區域 (Region)，以減少因為距離導致的網路延遲。
• 快取層 (Cache Layer)：加速熱門影片的傳播與播放。

串流網站的 API 範例

可能發生的效能問題

1. 影片卡頓問題：尖峰時段（例如同時 100 萬使用者觀看）導致媒體伺服器資源耗盡，出現影片卡頓或播放中斷。

2. CDN (Content Delivery Network) 部署範圍問題：全球用戶使用不同網路時，因 CDN 節點不足或頻寬不足，部分用戶播放體驗不佳。

3. 快取層 (Cache Layer) 設計不足：熱門影片未能及時在快取內，造成影片載入時間過長。

分析步驟

1. 了解系統背景，包含系統架構、溝通協定、可能會遇到的效能問題。
2. 針對測試目的，了解真實的業務模型，並且設計出合理的測試情境。
3. 決定效能測試的指標和監控，例如：多少用戶上傳影片，回應時間的合理範圍。

透過上面的資訊和步驟可以設計出測試情境，以下針對場景 1 所設計出來的測試情境。而這樣的測試叫做混合工作負載測試 (Mixed workload testing)

混合工作負載測試 (Mixed workload testing)

對一個系統進行多種不同類型的工作負載測試，這些工作可能包含讀取、寫入、資料處理或是網路請求等操作，透過模擬實際環境的不同需求，這種測試方法主要是測試執行不同類型的工作負在下系統的表現，並且確保系統能夠在這樣混合的情境下保持穩定和正常運作。

測試情境

測試情境 1：模擬用戶大量上傳影片，並且同時進行即時觀看，測試系統的寫入和讀取性能。

1. 分析系統背景，Web 伺服器是本次我們要測試的主要目標，
2. 針對測試目標，決定業務模型。通常可以透過過去歷史資料或合理計算評算要模擬 100 萬用戶同時在線，但其中 80 萬用戶進行即時關看影片，而 10 萬用戶則是上傳影片，10 萬用戶邊看影片邊上傳影片。
3. 決定效能測試的指標和監控：

K6 測試腳本

接著使用 K6 工具撰寫對應的測試腳本：這個腳本的目的是模擬 80 萬用戶觀看影片、10 萬用戶上傳影片，還有 10 萬用戶同時觀看和上傳影片，來測試系統在高負載下的效能。腳本分成不同的階段來模擬這些情境，並監控每秒的請求數和回應時間。

import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
    stages: [
        { duration: '1m', target: 800000 }, // 80 萬觀看影片的用戶
        { duration: '30s', target: 100000 }, // 10 萬上傳影片的用戶
        { duration: '30s', target: 100000 }, // 10 萬同時觀看和上傳影片的用戶
        { duration: '1m', target: 0 }, // 快速降載至 0
    ],
    thresholds: {
        'http_req_duration': ['p(95)<2000'], // 95% 的請求必須在 2 秒內完成
        'http_reqs': ['rate>100000'], // 每秒請求數需超過 10 萬
    },
};

export default function () {
    const userType = Math.floor(Math.random() * 3); // 隨機選擇行為：觀看、上傳或同時進行

    if (userType === 0) {
        // 模擬 觀看影片
        const res = http.get('http://localhost:3333/videos');
        check(res, {
            'response time < 2s': (r) => r.timings.duration < 2000,
            'status is 200': (r) => r.status === 200,
        });
    } else if (userType === 1) {
        // 模擬 上傳影片
        const res = http.post('http://localhost:3333/videos', { title: 'New Video', description: 'Test Video' });
        check(res, {
            'response time < 2s': (r) => r.timings.duration < 2000,
            'status is 200': (r) => r.status === 200,
        });
    } else {
        // 模擬 同時觀看和上傳影片
        const viewRes = http.get('http://localhost:3333/videos');
        check(viewRes, {
            'response time < 2s': (r) => r.timings.duration < 2000,
            'status is 200': (r) => r.status === 200,
        });

        const uploadRes = http.post('http://localhost:3333/videos', { title: 'New Video', description: 'Test Video' });
        check(uploadRes, {
            'response time < 2s': (r) => r.timings.duration < 2000,
            'status is 200': (r) => r.status === 200,
        });
    }

    sleep(1);
}

延伸練習

如果想要進一步挑戰，可以試著自己分析場景 2 和場景 3，並按照我們上面提到的步驟來設計和撰寫對應的測試場景與測試腳本。此外，試著找出上面測試腳本設定中的一些不合理之處，思考哪些地方可以進行調整或優化，這也是非常好的練習喔！

結論

在這次的效能測試中，我們模擬了多種情境，包括大規模用戶同時觀看、上傳影片，以及同時進行兩者的操作。透過這些測試場景，我們能夠及早發現系統在高負載下的潛在瓶頸，像是影片加載時間過長或上傳速度變慢等問題，讓我們在真正面對高流量時能更從容應對，並且不管今天是週幾，都值得放鬆一下，繼續前進！讓我們期待下次的挑戰，隨時保持最佳狀態！